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Beschreibung 



Verbindung von Teilnehmern in hybriden Kommunikationsnetzen 

5 ... 

In der Vergangenheit haben sich zwei wesentliche Typen von 
Kommunikationsnetzen zur Obermittlung von Informationen her- 
ausgebildet: Paketorientierte (Daten-) Netze und leitungsori- 
entierte (Sprach-) Netze. Im Zuge der Konvergenz dieser bei- 
10 den Netztypen haben sich konvergente (Sprach- Daten-) Netze 
herausgebildet . Durch Zusammenschluss dieser unterschiedli- 
chen Netztypen entstehen hybride Netze , in denen der Gegen- 
stand der vorliegenden Erfindung mit besonders schonen Vor- 
teilen zum Einsatz kommt. 

15 

Leitungsorientierte Netze - auch Sprachnetze oder Telephon- 
netze genannt - sind auf die Ubermittlung von in der Fachwelt 
auch als Gesprach, Call oder Session bezeichneten kontinuier- 
lich stromenden (Sprach-) Informationen ausgelegt. Die Uber- 

20 mittlung der Informationen erfolgt hierbei ublicherweise mit 
hoher Dienstgute und Sicherheit. Beispielsweise ist fur Spra- 
che eine minimale - z.B. < 200 ms - Verzogerung (Delay) ohne 
Schwankungen der Verzogerungszeit (Delay-Jitter) wichtig, da 
Sprache bei Wiedergabe im Empf angsgerat einen kontinuierli- 

25 chen Informationsf luss erfordert. Ein Informationsverlust 
kann deshalb nicht durch ein nochmaliges Obermitteln der 
nicht ubermittelten Information ausgeglichen werden und fuhrt 
ira Empf angsgerat Ublicherweise zu einem akustisch wahrnehmba- 
ren Knacksen. In der Fachwelt wird die ttbermittlung von Spra- 

30 che verallgemeinert auch als Echtzeit- (Obermittlungs-) Dienst 
bzw. als 'Realtime-Service 1 bezeichnet. 

Paketorientierte Netze - auch Datennetze genannt - sind auf 
die Oberraittlung von in der Fachwelt auch als 'Datenpaket- 
35 strome' oder 'Flow' bezeichneten Paketstromen ausgelegt. 

Hierbei muss Ublicherweise keine hohe Dienstgute garantiert 
werden. Ohne garantierte DienstgUte erfolgt die ttbermittlung 
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der Datenpaketstrome z.B. mit zeitlich schwankenden Verzo- 
gerungen, da die einzeXnen Datenpakete der Datenpaketstrome 
iiblicherweise in der Reihenfolge ihres Netzzugangs ttbermit- 
telt werden, d.h. die zeitlichen Verzogerungen werden uraso 
5*- grdfier/ je mehr Pakete von einem Datennetz zu ubermitteln 

sind. In der Fachwelt wird die Obermittlung von Daten deshalb 
auch als tibermittlungsdienst ohne Echtzeitbedingungen bzw. 
als ■ Non-Realtime-Service 1 bezeichnet. 

10 Die Pakete konnen beispielsweise je nach Art des paketorien- 
tierten Netzes als Internet-, X.25- oder Frame-Relay- Pakete, 
aber auch als ATM-Zellen ausgebildet sein. Sie werden zuwei- 
len auch als Nachrichten bezeichnet, v. a. dann, wenn eine 
Nachricht in einem Paket iibermittelt wird. 

15 

Ein bekanntes Datennetz ist das Internet. Dieses wird wegen 
des dort zum Einsatz kommenden Internet Protokolls IP zuwei- 
len auch IP-Netz genannt, wobei dieser Begriff grands at zlich 
weit zu verstehen ist und alle Netze umfasst, in denen das IP 
20 Protokoll eingesetzt wird. Das Internet ist als offenes 
(Weitverkehrs-) Datennetz mit offenen Schnittstellen zur 
Verbindung von (zumeist lokalen und regionalen) Datennetzen 
unterschiedlicher Hersteller konzipiert. Es stellt eine 
herstellerunabhangige Transportplattf orm zur Verfugung. 

25 

Verbindungen sind Kommunikationsbeziehungen zwischen zumin- 
dest zwei Teilnehmern zum Zweck einer - zumeist gegenseiti- 
gen, d.h. bi-direktionalen - Inf ormat ion siibermitt lung . Der 
die Verbindung initiierende Teilnehmer wird ublicherweise als 

30 'A-Teilnehmer 1 bezeichnet. Ein durch eine Verbindung mit 

einem A-Teilnehmer in Verbindung gesetzter Teilnehmer heifit 
'B-Teilnehmer 1 . In einem verbindungslosen Netz reprasentieren 
Verbindungen zumindest die auf logisch abstrakter Ebene ein- 
deutige Beziehung zwischen A- und B-Teilnehmer, d.h. entspre- 

35 chend dieser Sichtweise stellen z.B. die verbindungslosen 

Flows im Internet logisch abstrahierte Verbindungen dar (z.B. 
A-Teilnehmer = Browser und B-Teilnehmer = Web Server) . In 



einem verbindungsorientierten Netz reprasentieren Verbindun- 
gen zudem auf physikalischer Ebene eindeutige Wege durch das 
Netz, entlang denen die Inf ormationen iiberraittelt werden. 

Im Zuge der Konvergenz von Sprach- und Datennetzen werden 
Sprachubermittlungsdienste und zunehmend auch breitbandigere 
Dienste wie z.B. ttbermittlung von Bewegtbildinf ormationen 
ebenfalls in paketorientierten Netzen realisiert, d.h. die 
Ubermittlung der bisher iiblicherweise leitungsorientiert 
tibermittelten Echtzeitdienste erfolgt in einem konvergenten 
Netz - auch Sprach-Daten-Netz genannt - paketorientiert, d.h. 
in Paketstromen . Diese werden auch Echtzeitpaketstrome ge- 
nannt. Die ttbermittlung von Sprachinf ormationen uber ein 
paketorientiertes IP Netz wird dabei auch mit 'VoIP 1 (Voice 
over IP) gekennzeichnet . 

In den internationalen Standardisierungsgremien IETF (Inter- 
net Engineering Task Force) und ITU (International Telecommu- 
nications Union) mehrere Architekturen fur Sprach-Daten-Netze 
beschrieben. Allen ist gemeinsam, dass die Call Control Ebene 
und die Resource Control Ebene funktional deutlich voneinan- 
der getrennt sind. 

Die Call Control Ebene umfasst dabei zumindest einen (optio- 
nalen) Call Controller, dem u.a. folgende Funktionen zugeord- 
net sind: 

- Address Translation: Umsetzung von E.164 Telephonnummern 
und anderen Alias Adressen (z.B. Rechnernamen) auf Trans- 
portadressen (z.B. Internetadressen) . 

- Admission Control (optional) : Grundsatzliche Zulassig- 
keitsprufung, ob und in welchem Umfang (z.B. VoIP fahige) 
Einrichtungen das Kommunikationsnetz nutzen diirfen. 

- Bandwidth Control (optional) : Verwaltung von Obermitt- 
lungskapazitaten . 

- Zone Management: Registrierung von (z.B. VoIP fahigen) 
Einrichtungen und Bereitstellung obiger Funktionen fur al- 
le beim Call Controller registrierten Einrichtungen. 
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4 



Optional konnen einem Call Controller zudem folgende Funktio- 
nen fallweise zugeordnet werden: 

- Call Control Signalling: Alle Signalisierungsnachrichten 
5 werden von zumindest einem Call Controller vermittelt, 

d.h. alle Einrichtungen schicken und erhalten Signalisie- 
rungsnachrichten nur iiber den Call Controller- Ein direk- 
ter Austausch von Signalisierungsnachrichten zwischen den 
Einrichtungen ist untersagt. 
10 - Call Authorization: Zulassigkeitspruf ung £iir eingehende 
und ausgehende Calls. 

- Bandwidth Management: Steuerung der zulassigen Anzahl von 
Einrichtungen, die gleichzeitig das Kommunikationsnetz 
nut z en dtirfen. 

15 - Call Management: Verwaltung einer Liste bestehender Ge- 
sprache, urn z.B. ein Besetzzeichen erzeugen zu konnen, 
falls dies von der Einrichtung selbst nicht erzeugt werden 
kann . 

- Alias Address Modification: Ruckgabe einer modif izierten 
20 Alias Adresse, bspw. mit einer H. 2 2 5.0 Nachricht ACF (Ad- 
mission Confirmation) . Diese Adresse muss der Endpunkt bei 
Verbindungsauf bau verwenden . 

- Dialed Digit Translation: tibersetzung der gewahlten Zif- 
fern in eine E.164 Telephonnummer oder eine Nummer aus ei- 

25 nem privaten Nummerierungsschema . 

Beispiele fur Call Controller stellen der von der ITU in der 
H.323 Standard Familie vorgeschlagene 'Gatekeeper' oder der 
von der IETF vorgeschlagene 1 SIP Proxy' dar. Wird ein grofie- 

30 res Kommunikationsnetz in mehrere Domanen - auch 'Zonen' 

genannt - gegliedert, kann in jeder Domane ein separater Call 
Controller vorgesehen werden. Eine Domane kann auch ohne 
einen Call Controller betrieben werden. Sind mehrere Call 
Controller in einer Domane vorgesehen, soil nur ein einziger 

35 von diesen aktiviert sein. Ein Call Controller ist aus logi- 
scher Sicht getrennt von den Einrichtungen zu sehen. Physika- 
lisch muss er jedoch nicht in einer separaten Call Controller 
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Einrichtung realisiert sein, sondern kann auch in jedem End- 
punkt einer Verbindung (beispielsweise ausgebildet als H.323 
Oder SIP Endpunkt, Endgerat, Media Gateway, Multipoint 
Control Unit) oder auch einer primar zur programmgesteuerten 
5 Datenverarbeitung ausgebildeten Einrichtung (beispielsweise: 
Rechner, PC, Server) vorgesehen werden. Auch eine physika- 
lisch verteilte Realisierung ist moglich. 

Die Resource-Control-Ebene umfasst zumindest einen Resource- 
10 Controller, dem u.a. folgende Funktionen zugeordnet sind: 

- Capacity Control: Steuerung des dem Kommunikationsnetz 
durch Paketstrome zugefiihrten Verkehrsvo lumens, z.B. durch 
Kontrolle der fjbermittlungskapazitat einzelner Paketstro- 
me. 

15 - Policy Activation (optional) : ggf . fur einen priorisierten 
Paketstrora Resourcen im Kommunikationsnetz fur dessen 0- 
bermittlung reservieren. 

- Priority Management (optional) : Prioritatskennzeichen in 
den Paketen entsprechend der Prior itat ihrer Paketstrome 

20 setzen, kontrollieren und gegebenenf alls korrigieren, 

falls die Pakete bereits mit Prioritaten gekennzeichnet 
sind. 

Der Resource Controller wird auch als 'Policy Decision Point 
25 (PDP) 1 bezeichnet. Er ist beispielsweise innerhalb von sog. 
Edge Rout em - auch Edge Device, Zugangsknoten oder bei Zu- 
ordnung zu einem Internet Service Provider (ISP) auch Provi- 
der Edge Router (PER) genannt - realisiert. Diese Edge Router 
konnen auch als Media Gateway zu anderen Netzen ausgebildet 
30 sein, mit denen die Sprach-Daten-Netze verbunden werden. 

Diese Media Gateway sind dann sowohl mit einem Sprach-Daten- 
Netz als mit den anderen Netzen verbunden und dienen intern 
der Umsetzung zwischen den unterschiedlichen Protokollen der 
verschiedenen Netze. Der Resource Controller kann auch nur 
35 als Proxy ausgebildet sein und Resource Controller relevante 
Informationen an eine separate Einrichtung weiterleiten, auf 
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dem der Resource Controller realisiert 1st. 

Das prinzipielle Zusammenwirken von Call Controller und Re- 
source Controller gemafi dera Session Initiation Protokoll 
5 (SIP) der IETF bzw. der H.323 Protokollf amilie der ITU sei am 
Beispiel eines Call Setup zwischen zwei als Teilnehmerendge- 
rate ausgebildeten VoIP Einrichtungen erlautert. Dabei wird 
zunachst von einera homogenen Sprach-Daten-Netz ausgegangen. 

10 Innerhalb oder teilweise auch zeitlich vor dem eigentlichen 
Call Setup laufen bei Einwahl eines Endgerats in das IP-Netz 
(z.B. uber einen Internet Service Provider) die Schritte 
Authentisierung, Autorisierung und (Start des) Accounting ab. 
Diese sogenannte 'AAA' Funktionalitat wird ublicherweise 

15 durch den Zugriff auf eine Subscriber-Datenbank, in der alle 
Nutzer mit ihren Kennungen, Passwortem, Rechten, etc. ge- 
speichert sind, realisiert. Dieser Zugriff ist langsam und 
vergleichsweise komplex. In den heutigen "Best Effort" IP 
Netzen findet dieser AAA Vorgang normalerweise einmal wahrend 

20 des Einwahlens des Nutzers statt. Eine weitere Authentisie- 
rung erfolgt bei Einsatz eines Call Controllers, wenn sich 
das Endgerat beim Call Controller des Internet Service Provi- 
ders registriert. Nach dem ITU-Standard H.323 wird diese 
Authentisierung bzw. Registrierung eines Endgerats beim zuge- 

25 ordneten Gatekeeper gemafi dem RAS (Registration, Admission, 
Status) Protokoll durchgefuhrt, das im ITU-Standard H. 225.0 
beschrieben ist. 

Der eigentliche Call Setup beginnt ublicherweise damit, dass 
30 in einem ersten Schritt die Endgerate der Teilnehmer ihre 

Fahigkeiten (z.B. Liste der unterstutzten CODEC) austauschen, 
urn die benotigten Ressourcen (z.B. Bandbreite) und die gefor- 
derte QoS (z.B. Delay, Jitter) zu bestimmen. Die Endgerate 
sind bei Sprachtelephonie z.B. als IP-Telephone ausgebildet, 
35 bei Online-Video ware eines der Endgerate ein Content- bzw. 
Application-Server, z.B. im Netz des ISP. 
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Der Austausch der Signalisierungsnachrichten erfolgt entweder 
direkt zwischen den Endgeraten Oder unter Vermittlung eines 
Call Controllers. Hierbei 1st bei jedem Call fur jedes Endge- 
rat und fur jede Obertragungsrichtung individuell festgelegt, 
5 welche Variante zura Einsatz kommt. Die erste Variante wird in 
der H.323 Terminologie auch als 'Direkt Endpoint Call Signal- 
ling' und die zweite als 'Gatekeeper Routed Call Signalling' 
bezeichnet. Bei Direct Endpoint Call Signalling konnen an 
einen Call Controller ggf. Kopien ausgewahlter Signalisie- 
10 rungsnachrichten iibermittelt werden, so dass ein Call- 
Controller auch bei dieser Variante haufig Kenntnis von den 
zwischen den Endgeraten abgestimmten Ressourcen- und QoS- 
Anforderungen hat. Diese Anf orderungen werden jedoch von ihrn 
selbst nicht aktiv beeinflusst oder verifiziert. 

15 

In einem zweiten, optionalen Schritt kann die derart abge- 
stinimte Ressourcen- und QoS-Anf orderung direkt von den Endge- 
raten der Teilnehmer an ihren zugeordneten Resource Control- 
ler ubermittelt werden. Nach Prufung der Ressourcen- und QoS- 
20 Anforderung wird von dem Resource Controller eine Bestatigung 
(oder Ablehnung) an das Endgerat zuruckgeschickt . 

In einem dritten, ebenfalls optionalen Schritt wird im Edge 
Router und gegebenenfalls weiteren Routern im Netz eine Poli- 
25 cy aktiviert, mit der diese Router prufen und gewahrleisten, 
dass der vom Endgerat verursachte Verkehr innerhalb der Gren- 
zen liegt, die in der Anforderung spezifiziert wurden . Ein 
Beispiel fur einen derartigen Reservierungsmechanismus ist 
RSVP (resource Reservation Protocol) . 

30 

Zur Durchfuhrung der drei Schritte wird eine Mehrzahl von 
Nachrichten versendet, die lediglich zur Abstimmung der be- 
teiligten Komponenten untereinander , jedoch nicht zur tiber- 
mittlung der "eigentlichen Inf ormationen" zwischen den Endge- 
35 raten dienen. Diese mit den Nachrichten ubermittelten Inf or- 
mationen werden Ublicherweise als Signalisierungsinf ormatio- 
nen, Signalisierungsdaten bzw. schlicht als Signalisierung 
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bezeichnet. Der Begriff 1st dabei weit zu verstehen . So sind 
z.B. neben den Signal! sierungsnachrichten auch die Nachrich- 
ten geraafi dem RAS Protokoll, die Nachrichten gemafi dem ITU- 
Standard H.245 zur Steuerung von Nutzkanalen bestehender 
5 Gesprache sowie alle weiteren ahnlich ausgebildeten Nachrich- 
ten umfasst. Das Signalisierungsprotokoll fur den Verbin- 
dungsaufbau (Call Setup) und -abbau (Call Release) nach der 
ITU ist z.B. im Standard H. 225.0 beschrieben, das nach der 
IETF ira RFC 2453bis ("SIP: Session Initiation Protocol") . Die 
10 "eigentlichen Informationen" werden zur Unterscheidung von 

der Signal! sierung auch Nutzinf ormationen, Payload, Medienin- 
formationen, Mediendaten oder schlicht Medien genannt. 

Kommunikationsbeziehungen, die zur Obermittlung der Signali- 
15 sierung dienen, werden im weiteren auch als Signalisierungs- 
verbindungen bezeichnet. Die zur Ubermittlung der Nutzinf or- 
mationen eingesetzten Kommunikationsbeziehungen werden z.B. 
Sprechverbindung, Nutzkanalverbindung oder - vereinfacht - 
Nutzkanal, Bearerchannel oder schlicht Bearer genannt. 

20 

Bei Zusammenschluss eines derartigen konvergenten Sprach- 
Daten-Netzes mit einem konventionellen leitungsorientierten 
Sprachnetz entstehend bei Ubermittlung von Informationen uber 
die Grenzen der jeweiligen Netze hinweg neue technische Prob- 
25 lemstellungen aufgrund der unterschiedlichen Technologies 
die in den jeweiligen Netztypen zum Einsatz kommen. 

Es ist Aufgabe der Erfindung, zumindest eines dieser Probleme 
zu erkennen und durch Angabe von zumindest einer Ldsung den 
30 Stand der Technik zu bereichern. 

Die Erfindung stellt sich die Frage, warum es die VoIP Tech- 
nologie es bis heute nicht geschafft hat, sich f lachendeckend 
als Alternative zur konventionellen, leitungsorientierten 
35 Telephonnetzen durchzusetzen . Wahrend sich VoIP innerhalb von 
privaten (Unternehmens-) Netzen schon etablieren konnte, ist 
dies in offentlichen Netzen - auch Public Switched Telephone 
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Network (PSTN) genannt - noch nicht erfolgt. Die fortschrei- 
tende Verbreitung von sogenannten Messenger Applikationen auf 
privat benutzten Rechnern - auch Personal Computer (PC) ge- 
nannt - erlaubt zwar mittlerweile auch den Aufbau von Sprech- 
5 verbindungen von PC zu PC. Telephonate vora PC aus in das 

offentliche Telefonnetz sind aber immer noch nicht weit ver- 
breitet . 

Ein Grund fur diese langsame Verbreitung von VoIP in hybriden 
10 Netzen, die auch ein offentliches Telephonnetz umfassen, 

liegt aus Sicht der Erfindung in der Vergebuhrung. Bei der 
Oberleitung der Verbindung in das PSTN entstehen fur den 
Betreiber des PSTN Kosten, die letztendlich der anrufende 
Teilnehmer tragen muss. Diesen Teilnehmer eindeutig zu iden- 
15 tifizieren und ihm nachtraglich die Kosten fur sein Gesprach 
in Rechnung zu stellen ist jedoch schwierig und wurde bisher 
noch nicht zuf riedenstellend gelost. 

Es ist bekannt, dass sich VoIP Teilnehmer eine Client Soft- 
20 ware auf ihrem PC installieren und sich mit Hilfe dieser 

Software im folgenden auf dem zentralen Kommunikations server 
ihres VoIP Providers (z.B. MSN, Yahoo) registrieren . Da sich 
alle Nutzer einer bestimmten Client Software ublicherweise 
bei dem gleichen zentralen Server registrieren, ist es tech- 
25 nisch vergleichsweise einfach, Kommunikationsbeziehungen 
zwischen alien registrierten Teilnehmern herzustellen . Da 
diese Verbindungen innerhalb des IP Netzes bleiben, fallen 
auch keine Gesprachsgebuhren an, die man den Teilnehmern in 
Rechnung stellen musste. 

30 

Anders verhalt es sich, wenn man mit solch einer Client Soft- 
ware ein Gesprach in das PSTN aufbauen will. Der VoIP Provi- 
der muss in diesem Fall die Verbindung uber einen Media Gate- 
way zu einem bestimmten PSTN fuhren (routen) . Der Betreiber 
35 des PSTN (PSTN Betreiber) hat dann iiblicherweise ein Abrech- 
nungsabkommen mit dem VoIP Provider, urn ihm die anfallenden 
Verbindungskosten in Rechnung zu stellen. Der VoIP Provider 
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wird seinerseits das Geld vom Nutzer der Clientsof tware ein- 
f ordern . 

Dieses Verfahren 1st zumindest fur zwei der beteiligten Par- 
5 teien rait Nachteilen behaftet: 

- Der PSTN Betreiber muss sein Netz mit einer Vielzahl ver- 
schiedener VoIP Providern zusammenschliefien . Weiterhin 
muss er fur jeden dieser VoIP Betreiber ein individuelles 

10 Abrechnungsverfahren etablieren. Er kann aber trotzdem die 

VoIP Teilnehmer nicht direkt adressieren, um z.B. seinen 
Dienst zu bewerben oder direkte Rechnungen zu stellen, da 
er keine verlassliche Mdglichkeit der Teilnehmeridentif i- 
zierung hat. 

15 

- Der VoIP Teilnehmer ist bei den PSTN Verbindungen von den 
Konditionen abhangig, die ihm sein VoIP Provider anbietet. 
Dies begrenzt die Flexibilitat der VoIP Teilnehmer, wenn 
der NetzObergang per Media Gateway nur zum PSTN eines oder 

20 weniger PSTN Betreiber realisiert wird. Diese Begrenzung 

wird verstarkt, wenn bei einem weltweit agierenden VoIP 
Provider diese reduzierte Auswahl von PSTN Betreiber in 
vielen Lander besteht. 

25 Eine Losung fur diese der Erfindung zugrunde liegende Prob- 
lemsituation ist in den Patentanspriichen angegeben. 

Mit dieser Losung sind eine Vielzahl von Vorteilen verbunden : 

30 - Durch die Zuweisung der Teilnehmeridentif ikat ion zu einem 
Server wird die bisherige starre Konf iguration aufgelost, 
bei der die Identitat eines VoIP Teilnehraers nur seinem 
zugeordneten VoIP Provider bekannt ist. Diese Flexibili- 
sierung ermoglicht andere Konf igurationen, bei denen je 

35 nach deren Ausbildung auch anderen als dem VoIP Provider 

die Identitat des A-Teilnehmers bekannt sein kann. Insbe 
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sondere kann dieser Andere auch ein PSTN Betreiber sein. 

- Durch die Verschiebung des Aufbaus der Signalisierungsver- 
bindung in das PSTN, die bislang im Anschluss an den Ver- 

5 bindungswunsch des A-Teilnehmers vom VoIP Betreiber aus- 

ging, hin zu dem Server wird die Vergebuhrung vom VoIP 
Provider entkoppelt, weil die Vergebuhrung ublicherweise 
demjenigen zugeschrieben wird, der den Aufbau einer Ver- 
bindung initiiert, d.h. vorliegend dem Betreiber des Ser- 
10 ver und nicht mehr dem VoIP Betreiber. 

- Ein PSTN Betreiber kann bei Entkopplung von Server und 
VoIP Betreiber direkt Endkunden fur seinen Dienst gewin- 
nen, ohne auf die Zusammenarbeit mit einem VoIP Provider 

15 angewiesen zu sein. 

- Diese Entkoppelung ermoglicht eine Zentralisierung, bei 
der weniger Server als VoIP Provider vorgesehen sind. In 
diesem Fall reduziert sich die Anzahl der Server, fur die 

20 von den PSTN Betreibern ein individuelles Abrechnungsver- 

fahren etablieren muss, wodurch vorteilhaft eines der von 
der Erfindung erkannten Probleme gelost wird. 

- Im Falle der durch die Erfindung ermoglichten Option einer 
25 Zentralisierung des Servers ist wegen der dann geringeren 

Anzahl von Servern, die ggf . zudem im Wettbewerb zueinan- 
der stehen, eine Anbindung an mehrere PSTN Betreiber zu 
erwarten, weil die Anzahl der Anbindungen sinkt und somit 
leichter handhabbar wird und der Wettbewerb infolge der 
30 dort gebotenen Dif f erenzierung der unterschiedlichen Ser- 

ver die Ausbildung eines breiten Angebots an PSTN Betrei- 
bern fordert. Dies verringert das Problem der VoIP Teil- 
nehmer, in ihrer Auswahl von PSTN Betreibern beschrankt zu 
sein. 

35 
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Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben 
sich aus den unter- oder nebengeordneten Anspruchen. 

Bei Ausbildung des Servers als WEB Applikation, d.h. als 
5 Computerprogramm, auf das mit einem beliebigen, zeitgemafien 
Browser (z.B. Microsoft Interner Explorer, Netscape Communi- 
cator) durch Angabe einer weltweit eindeutigen URL wahlfrei 
zugegriffen werden kann, wird eine vollstandige Entkopplung 
zwischen dem physikalischen Netzzugang von Teilnehmern und 
10 der Anordnung des Server bewirkt. Dies bedeutet, dass der 

Server prinzipiell an einem beliebigen Ort weltweit positio- 
niert werden kann. 

Bei Erfassung der IP Adresse eines auf die WEB Applikation 
15 zugreifenden Teilnehmers kann diese automatisch den ankommen- 
den IP Paketen entnommen werden, so dass vorteilhaft keine 
manuelle Eingabe der IP Adresse erforderlich ist. In diesem 
Fall ist nur die manuelle Erfassung derjenigen Daten erfor- 
derlich, durch die der gerufene Teilnehmer gekennzeichnet 
20 wird. 

Durch eine Anfrage bei dem Teilnehmer, des sen IP Adresse 
bekannt ist, kann ermittelt werden, welche Client Software 
bei diesem Teilnehmer zur Nutzung von VoIP zum Einsatz kommt. 

25 Dies fuhrt zu dem Vorteil, dass der VoIP Teilnehmer nicht 

mehr, wie heute noch iiblich, eine spezielle Client Software 
installieren muss. Der VoIP Teilnehmer muss sich nicht mehr 
auf einen bestimmen VoIP Provider festlegen und dessen Client 
auf seinem PC installieren, wodurch er auf die PSTN Betreiber 

30 festgelegt wird, die mit dem VoIP Provider ein Abrechnungs- 
verfahren etabliert haben. Er kann stattdessen aus einer 
Vielzahl von PSTN Betreibern den fur seine Bedurfnisse geeig- 
netsten heraussuchen und direkt von diesem abgerechnet wer- 
den . 

35 

Durch Bestimmung der Identitat eines Teilnehmers - bspw. 
durch Relationen seiner kennzeichnenden Daten mit einer be 



WO 2005/013577 



PCT/EP2004/050688 



13 

stehenden Registrierungsdatenbank, kann eine unmittelbare 
Vergebuhrung an diesen Teilnehmer mithilfe der in der Regist- 
rierungsdatenbank hinterlegten Daten erfolgen. Dies wird 
vorzugsweise dadurch unterstutzt, dass von dem Server der 
5 Aufbau eines Bearer unterstutzt und dabei die Zeitdauer des 
Bestehens des Bearers durch einen Vergebuhrungsdatensatz 
protokolliert wird. Zur Vermeidung von inkonsistenten Verge- 
btihrungsdatensatzen wird dabei vorzugsweise das Bestehen des 
Bearers mit einem Timer Mechanismus iiberwacht, der z.B. als 
10 Watchdog ausgebildet sein kann und von dem Server ausgeht. 

Schone Vorteile geben sich, wenn der Server einem PSTN 
Betreiber zugeordnet wird. Ein PSTN Betreiber kann dann im 
Idealfall seinen Kunden sogar die anfallenden Gesprachsgebuh- 

15 ren ohne jegliche Registrierung direkt liber die normale Fern- 
melderechnung abrechnen. Ein Beispiel hierfiir ist ein VoIP 
Teilnehmer, der per T-DSL und T-Online auf erf indungsgemafien 
VoIP Server der Deutschen Telekom zugreift. Der Server der 
Deutschen Telekom kann dann iiber die bei T-Online verwaltete 

20 IP Adresse des VoIP Teilnehmer s eindeutig auf das PSTN Fern- 
meldekonto des Teilnehmer s schlieflen. Eine separate Prozedur 
zur Authentifizierung des Teilnehmers kann entf alien. 

Die Erfindung wird im folgenden anhand von weiteren Ausfiih- 
25 rungsbeispielen, die auch in den Figuren dargestellt sind f 
erlautert. Es zeigt hierbei: 

Figur 1 eine Anordnung zur Durchfiihrung des erf indungsgema- 
fien Verfahrens mit einem hybriden Kommunikations- 
30 netz, bestehend aus einem paketorientierten Inter- 

net , einem leitungsorientierten PSTN, einem zwi- 
schengeschalteten Media Gateway und Media Gateway 
Controller sowie zwei Endpunkten einer Informati- 
on stibermitt lung 

35 

Figur 2 ein Ablauf diagramm, in dem eine Ausftihrung des 
erfindungsgemafien Verfahrens exemplarisch aufge 
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zeigt 1st 

In Figur 1 1st eine beispielhaf te Anordnung zur Durchfiihrung 
des erfindungsgemafien Verfahrens dargestellt. Es sei betont, 
5 dass die hierbei aufgezeigten Ausfuhrungen dabei trotz ihrer 
teilweise detailgetreuen Darstellung lediglich beispielhaf ter 
Natur und nicht einschrankend zu verstehen sind. Sie unifasst 
ein leitungsorientiertes Kommunikationsnetz PSTN und ein 
paketorientiertes Kommunikationsnetz IN, die durch ein zwi- 

10 schengeschaltetes Media Gateway zur Konvertierung zwischen 
unterschiedlichen, netzspezif ischen Nutzkanaltechnologien 
RTP/RTCP (Real Time [Control] Protocol) und TDM (Time Devisi- 
on Multiplex) und einen zwischengeschalteten Media Gateway 
Controller zur Konvertierung zwischen unterschiedlichen netz- 

15 spezifischen Signalisierungsprotokollen SIP (Session Initia- 
tion Protocol) und SS7 (Signalling System No. 7) zu einem 
hybriden Netz zusammengeschlossen sind. Das Gateway MG wird 
dabei von dem Controller MGC durch ein - vorzugsweise inter- 
national genormtes - Protokoll, z.B. MGCP (Media Gateway 

20 Control Protocol) oder H.248 gesteuert . Das Netz IN ist vor- 
zugsweise als das Internet ausgebildet. Fur den einschlagigen 
Fachmann ist dabei of f ensichtlich, dass die Erfindung selbst- 
verstandlich in weiteren paketorientierten Netzen zura Einsatz 
kommen kann wie z.B. Intranet, Extranet, einem lokalen Netz 

25 (Local Area Network - LAN) oder einem, z.B. als Virtuelles 

Privates Netz (VPN) ausgebildeten f irmeninternen Netz (Corpo- 
rate Network) . 

An das Netz IN ist ein Server S angeschlossen, auf den z.B. 

30 mit Hilfe eines IP basierten Protokolls HTTP zugegriffen 

wird. Der Server S umfasst bspw. als Computerprogrammprodukt 
P ausgebildete Applikationen APL, insbesondere WEB Applikati- 
onen, die Sof twarecodeabschnitte zur (multi-) prozessorge- 
stiitzten Ausftthrung des erf indungsgemaBen Verfahrens umfas- 

35 sen. Optional konnen dabei Teile der Computerprogramraprodukte 
P auch mit Hilfe von spezieller Hardware (z.B. Signalling- 
Prozessoren) realisiert sein. Dera Server zugeordnet ist eine 
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Teilnehmerdatenbank zur Identif ikation, Registrierung und/ 
oder Verifikation von Teilnehmern und deren Rechten, auf die 
z.B. mit einem entsprechenden Protokoll LDAP (Lightweigth 
Directory Access Protocol) zugegriffen wird. 

5 

Ein erster Teilnehmer A ist dem Netz IN, ein zweiter Teilneh- 
mer B dem Netz PSTN zugeordnet. Der Zugriff auf das Netz IN 
wird mit Hilfe einer bekannten IP Anschlusstechnik (z.B. IP 
over xDSL, gesteuert durch das Protokoll PPP und vermittelt 
10 durch einen zwischengeschalteten ISP zur dynamischen Vergabe 
von IP Adressen fur die - meist zeitlich begrenzte - eindeu- 
tige Adressierung des Teilnehmers A im Netz IP) , der auf das 
Netz PSTN mit Hilfe einer bekannten TDM Anschlusstechnik 
(z.B. ISDN, gesteuert durch das Protokoll DSS1) bewirkt. 

15 

In Figur 2 ist eine Ausfiihrung des erf indungsgemaften Verfah- 
• rens am Beispiel eines exemplar! schen, zeitlichen Verlaufs 
eines Gesprachs CALL zwischen den beiden Teilnehmern A, B rait 
Hilfe eines Ablaufdiagramms dargestellt. In dem Diagramm sind 

20 standardisierte (Signalisierungs-) Nachrichten SIP:INVITE, 
100 TRYING, 180 RINGING, 200 OK, SIPrACK und SIP:BYE zum 
Austausch von Signalisierungsdaten zwischen dem Teilnehmer A, 
dem Server S und dem Controller MGC aufgezeigt. Diese Nach- 
richten sind dem standardisierten Protokoll SIP entnommen, 

25 das bei der IETF fur die Steuerung von Verbindungen RTP zwi- 
schen Endpunkten einer RTP Verbindung entwickelt wurde. Im 
vorliegenden beispielhaften Ablauf diagramm sind diese End- 
punkte als Teilnehmer A und Gateway MG ausgebildet. Fur den 
Fachmann ist of f ensichtlich, dass andere Signalisierungspro- 

30 tokolle, z.B. die der Protokollf amilie H.323, mit gleicher 
Wirkung eingesetzt werden konnen. 

Als wei teres Ausf Uhrungsbei spiel der Erfindung wird ein Zu- 
sammenwirken des VoIP Teilnehmers A (bzw. dessen VoIP Clients 
35 C) , des Servers B, des Controllers MGC, des Gateways MG End- 
punkts A und des PSTN Teilnehmers B (bzw. dessen Telephon T) 
ausgefuhrt, bei dem es einem PSTN Betreiber ermoglicht wird, 
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Verbindungen von VoIP Teilnehmern zu PSTN Teilnehmern seines 
Netzes anzubieten und den initiierenden VoIP Anrufer direkt 
zu vergebiihren . Die dem Beispiel zugrunde liegende Netzkonfi- 
guration ist dabei Figur 1 abgebildet, wobei folgende Zuord- 
5 nungen angenommen werden: 

Komponenten des PSTN Betreibers: 

Das leitungsorientierte Netz PSTN 

- Der Media Gateway Controller MGC - hier auch IP-PSTN Gate- 
10 way genannt (z.B. ein hiQ9200 der Firma Siemens) 

- Mindestens ein Media Gateway MG {z.B. ein hiG1200 der 
Firma Siemens) 

Komponenten, auf die der VoIP Teilnehmer A seinen Zugang zum 
15 Netz IN stutzt: 

- Eine bestehende Onlineverbindung uber (s)einen Internet- 
provider ISP zum paketorientierten Internet IN 

- Einen beliebigen Web-Browser (z.B. einen Internet Explorer 
der Firma Microsoft) 

20 - Einen beliebigen, installierten VoIP Client C (z.B. einen 
SIP Sigma Client der Firma Siemens) 

Weiterhin kommt im diesem Ausf iihrungsbei spiel ein erfindungs- 
gemaBer WEB und/oder Applikation Server S zum Einsatz, der 
25 vorzugsweise dem PSTN Betreiber zugeordnet ist. 

Im beschriebenen Szenario kommuniziert der Server S sowohl 
mit dem IP- PSTN Gateway MGC als auch mit dem VoIP Client C 
des Teilnehmers A uber das standardisierte SIP Protokoll 
30 (Session Initiation Protocol) . Das beschriebene Verfahren ist 
aber grundsatzlich auch bei Verwendung anderer Signalisie- 
rungsprotokolle moglich, z.B. mittels des H.323 Protokolls. 

Die Realisierung des Server S umfasst einen Webserver zur 
35 Unterstutzung des Protokolls HTTP und einen Applicationserver 
zur Durchfuhrung des erf indungsgemafien Verf ahrens . Der Server 
S ist beispielsweise als ein einziger physikalischer Server 
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(genannt Web /Application Server) ausgebildet. Beide Komponen- 
ten konnten genau so gut auf unterschiedlichen, miteinander 
vernetzten Servern liegen. 

Um eine Verbindung zum PSTN Teilnehmer B aufzubauen, geht der 
VoIP Teilnehmer A zum Zeitpunkt START mit seinem Browser 
durch Angabe einer bestimmten URL auf eine Webseite des 
Betreibers des Servers , durch die eine graphische Oberflache 
der Applikation API, realisiert wird. Vom Server S wird dar- 
aufhin optional eine Authentif izierung des Teilnehmers A 
durchgefuhrt. Hierfiir gibt es mehrere Moglichkeiten: 

- Der Teilnehmer A registriert sich einmalig beim Server S 
und meldet sich dann bei jedem weiteren Zugriff auf den 
Server S mit Usernaraen und Passwort an. 

- Die Teilnehmeridentif izierung erfolgt automatisch, z.B. 
anhand der IP Adresse des Teilnehmers A. Die IP Adresse 
des Teilnehmers kann der Server S bspw. anhand der von dem 
Teilnehmer A empfangenen HTTP Nachrichten erkennen, in de- 
nen ublicherweise dessen IP Adresse als Kennzeichnung der 
Quelle der Nachricht enthalten 1st. Diese Automatisierung 
ist beispielsweise dann mdglich, wenn der PSTN Betreiber 
mit dem ISP des VoIP Teilnehmers A identisch ist oder mit 
diesera kooperiert. 

Im Anschluss konnen von dem Server S optional die technischen 
Moglichkeiten bzgl. der Erreichbarkeit des VoIP Teilnehmers A 
ermittelt werden um herauszufinden, ob - und wenn ja - wie 
der VoIP Client angerufen werden kann. Auch hierfiir gibt es 
mehrere Moglichkeiten: 

- Der Teilnehmer A gibt seine SIP Adresse in einem Formular 
ein und der Web/Application Server S speichert diese Daten 
in einem Profil dieses Teilnehmers A ab, das in der Teil- 
nehmerdatenbank hinterlegt ist. 
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- Der Web/Application Server S ftihrt eine automatische 

Client-Erkennung durch. Er kann dazu beispielsweise eine 
SIP:OPTIONS Nachricht an den Port 5060 des Teilnehmer-PC s 
senden und aus einer empf angenen Antwort erkennen, ob und 
wenn ja, was fur ein Client C auf dem PC des VoIP Teilneh- 
mers A installiert ist . Wenn kein Client installiert bzw. 
instantiiert ist, kann keine Signalisierungsverbindung 
SIP [A] aufgebaut werden. Die Art des Client kann dazu 
verwendet werden, den Ablauf nach Figur 2 entsprechend auf 
die spezifischen Eigenarten des Clients C anzupassen, z.B. 
durch eine alternative ttbermittlung von Daten SDP. 

Daraufhin tragt der VoIP-Teilnehmer A in seinem Browser in 
ein Formular die Rufnummer des gewiinschten PSTN Teilnehmers B 
ein. Alternativ kann der PSTN Betreiber auch einen Telefon- 
buchdienst anbieten, mit dessen Hilfe ein einfacher Click auf 
einen bestimmen Eintrag zum Aufbau der Verbindung zwischen 
den beiden Teilnehmern A, B fuhrt. Der Web/Application Server 
S bestimmt aus dieser Adressinf ormation das zustandige IP- 
PS TN Gateway MGC. 

Der folgende Schritt zeigt einen deutlichen Unterschied zu 
bisherigen VoIP Verbindungen : Wahrend normalerweise der A- 
Teilnehmer (bzw. sein zugeordneter VoIP Betreiber) eine 
(Signalisierungs-) Verbindung zu einem B-Teilnehmer aufbaut, 
initiiert im hier beschriebenen Szenarium der Web/Application 
Server S zwei separate Signalisierungsverbindungen, eine 
erste SIP [A] zum VoIP Teilnehmer und eine zweite SIP [B] , 
SS7, DSS1 zum Teilnehmer B und schaltet diese anschliefiend zu 
einer durchgangigen Signalisierungsverbindung SIP, SS7, DSS1 
zusammen. 

Dabei wird infolge des hybriden Netzszenarios das Protokoll 
der zweiten Signalisierungsverbindung SIP [B] , SS7, DSS1 
mehrfach in bekannter Weise umgesetzt, und zwar das Protokoll 
SIP [B] , das zwischen dem Server und dem IP-PSTN Gateway MGC 
zum Einsatz kommt, von dem IP-PSTN Gateway MGC auf das Proto 
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koll SS7 des Netzes PSTN und letzteres dann vora Vermittlungs- 
knoten STP (Signalling Transfer Point) auf das Protokoll DSS1 
des Teilnehmeranschlusses. Diese Umsetzungen bleiben fur den 
Server S verborgen, so dass die zweite Signalisierungsverbin- 
dung SIP [B] , SSI, DSS1 virtuell zwischen dem Server S und 
dem Teilnehmer B besteht. Das IP-PSTN Gateway MGC wirkt, mit 
anderen Worten gesagt, gegenuber dem Server S als Proxy des 
Teilnehmers B. 

Neben dem Aufbau einer durchgangigen Signal! sierungsverbin- 
dung SIP, SS7, DSS1 ist die Durchschaltung einer Nutzkanal- 
verbindung / Bearers RTP, TDM zwischen den Teilnehmern A und 
B erforderlich. Diese setzt sich in diesem Beispiel aus einen 
paketorientierten Bearer RTP im Netz IN und einem leitungs- 
orientierten Bearer TDM im Netz PSTN zusamraen. Die Endpunkte 
des Bearers RTP im Netz IN sind dabei das Media Gateway MG 
sowie der VoIP Client C des Teilnehmers A, die des Bearers 
TDM im Netz PSTN das Media Gateway MG sowie das konventionel- 
le Telephon T des Teilnehmers B. 

Der Web/Application Server S unterstutzt dabei den gegensei- 
tigen Austausch von Inf ormationen, die fur den Aufbau des 
paketorientierten Bearers RTP benotigt werden. Dieser Aus- 
tausch erfolgt z.B. mit Hilfe des Protokolls SDP (Session 
Description Protocol), welches Bestandteil von SIP ist. Dabei 
ergeben sich besonders schone Vorteile, wenn der Standardab- 
lauf gemaA dem Offer-Answer Modell von SIP erhalten bleibt. 
Dieser Standardablauf sieht vor, dass auf der Seite des ru- 
fenden Teilnehmers in die Nachricht SIP: INVITE ein Datensatz 
SDP einfugt wird, der u.a. auch eine Liste aller CODEC ent- 
halt, die auf der Seite des rufenden Teilnehmers unterstutzt 
werden (= Offer) , und dass auf der Seite des geruf enen Teil- 
nehmers in die Nachricht 200 OK ein Datensatz SDP eingefiigt 
wird, in dem der fur das folgende Gesprach CALL zu verwenden- 
de CODEC angezeigt wird (= Answer) . Diese Dnterstiitzung ist 
im Ablaufdiagramm von Figur 2 naher erlautert: 
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Zunachst wird vom Server S eine Nachricht SIP: INVITE zum IP- 
PSTN Gateway MGC gesendet. Diese Nachricht konnte zwar schon 
die IP Adresse des Clients C enthalten, weil diese schon mit 
Zugang der ersten HTTP Nachricht bekannt ist. Es fehlen je- 
5 doch zu diesem Zeitpunkt fur einen erf olgreichen Aufbau des 
Bearers RTP zumindest noch die Angabe des Ports des Clients C 
sowie die Liste der CODEC, die von dem Client C unterstutzt 
werden, so dass die Nachricht SIP: INVITE keinen bzw. zumin- 
dest keinen vollstandigen SDP Datensatz enthalt. 

10 

Von dem IP-PSTN Gateway MGC wird daraufhin dem Server S mit 
einer Nachricht 100 TRYING angezeigt/ dass versucht wird, den 
Teilnehmer B zu erreichen, und der bekannte Aufbau des Bea- 
rers TDM im Netz PSTN durchgef iihrt . In diesem Zusammenhang 

15 werden im Media Gateway MG ein in das Netz PSTN fiahrender 

PSTN Port und ein in das Netz IP fuhrender RTP Port belegt . 
Die Signalisierung zwischen dem IP-PSTN Gateway MGC und dem 
Teilnehmer B gemafi dem Protokoll SS7 - dort insb. dem Proto- 
koll ISUP - und dem Protokoll DSS1 ist Stand der Technik und 

20 wird hier nicht naher beschrieben. Das gleiche gilt fur die 

Signalisierung zwischen dem IP-PSTN Gateway MGC und dem Media 
Gateway MG mit den Protokollen MGCP bzw. H.248. 

Nach erfolgreichem Aufbau des Bearers TDM wird im Netz PSTN 
25 der Klingelton angelegt und im Bearer TDM bis zum Media Gate- 
way MG iibermittelt. Vom IP-PSTN Gateway MGC wird die Nach- 
richt 180 RINGING an den Server gesendet, in der ein voll- 
standiger Datensatz SDP [MG] enthalten ist, insbesondere der 
RTP Port im Gateway MG sowie die Liste der von dem RTP Port 
30 des Media Gateway MG unterstutzten CODEC. 

Der Datensatz SDP [MG] wird von Server S dazu verwendet, um 
eine Nachricht SIP: INVITE zu erzeugen, die einen vollstandi- 
gen Datensatz SDP im Sinne einer Offer enthalt. Diese Nach- 
35 richt SIP: INVITE (SDP [MG] ) wird an den Teilnehmer A gesen- 
det. Mit anderen Worten: Die Nachricht SIP: INVITE in Richtung 
des Teilnehmers A wird in diesem Ausf Uhrungsbeispiel solange 
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verzogert, bis der Datensatz SDP [MG des] Media Gateways MG 
vom Server S empfangen wird. Dieser Ablauf konnte nach dem 
Offer/Answer-Modell von SIP selbstverstandlich auch variiert 
werden. Der hier beschriebene Ablauf resultiert aber in Rich- 
5 tung des Clients C in dem oben beschriebenen Standardablauf . 
Damit ist der besonders schone Vorteil verbunden, dass dieser 
Ablauf von alien SIP Clients C untersttitzt werden sollte. 

Nach Empfang der Nachricht SIP: INVITE beginnt der VoIP Client 
10 C des Teilnehmers mit der Anzeige des eingehenden Anrufs. 

Dies wird dem Server mit den ublichen Nachrichten 100 TRYING 
und 180 RINGING angezeigt. Sobald der Teilnehmer A den Ruf 
annimmt, wird an den Server S eine Nachricht 200 OK gesendet. 
Spatestens in diese Nachricht wird ein Datensatz SDP [A] 
15 eingefugt, mit dem u.a. der Port des VoIP Clients C und der 

ausgewahlte CODEC angezeigt wird. Der Bearer RTP kann bereits 
unidirektional vom Client C in Richtung des Media Gateways MG 
in Betrieb genommen werden. 

20 Fur eine Aktivierung der Gegenrichtung vom Media Gateway MG 
zu Client C ist noch erforderlich, den Datensatz SDP [A] an 
den Media Gateway MG weiterzuleiten . Sobald diese Daten vom 
Server S an den Media Gateway MGC weitergeleitet sind, kann 
der Bearer RTP bi-direktional in Betrieb genommen werden. Die 

25 Teilnehmer A und B konnen dann miteinander sprechen. 

Eine Moglichkeit zur Weiterleitung der Daten SDP [A] besteht 
darin, sie dem IP-PSTN Gateway mit der Nachricht SIP:ACK 
mitzuteilen, die als Bestatigung der Nachricht 200 OK iiber- 
30 mittelt wird, mit der angezeigt wird, dass der Teilnehmer B 
den eingegangen Ruf angenommen hat. 

Eine weitere Moglichkeit besteht darin, die Daten SDP [A] 
unmittelbar nach deren Empfang mit einer gesonderten Nach- 
35 richt SIPrxxx weiterzuleiten. Dies hat den Vorteil, dass mit 
Empfang der Daten SDP [A] der RTP Port des Media Gateway MG 
aktiviert und der bereits aus dem Netz PSTN anliegende Rufton 
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bis zum Abheben des Zielteilnehmers B als auch T6ne oder 
Ansagen (Besetzt, Fehlerfalle, usw.) an den Client C iibermit- 
telt werden konnen. 

5 Die Nachricht SIP:xxx kann als Nachricht SIP: UPDATE ausgebil- 
det sein. Dies stellt zwar einen bewussten Verstofc gegen das 
Offer-Answer Modell dar, well die Nachricht SIP: UPDATE grund- 
satzlich eine neue Offer darstellt. Diese kann jedoch durch 
eine entsprechende Anpassung des IP-PSTN Gateway MGC kompen- 
10 siert werden. 

Alternativ kann die Nachricht SIP:xxx als Nachricht SIP:PRACK 
ausgebildet sein. Zur Unterstiitzung dieser Alternative wird 
dabei in der vorausgegangen Nachricht SIP: INVITE dem IP-PSTN 

15 Gateway MGC angezeigt, das "reliable provisional responses" 
unterstutzt wird. In diesem Fall iibermittelt das IP-PSTN 
Gateway MGC die Daten SDP [MG] schon in der Nachricht 180 
RINGING und erwartet daraufhin die Nachricht SIP:PRACK als 
Bestatigung. In diese Bestatigung werden dann die von Teil- 

20 nehmer A empf angenen Daten SDP [A] eingefugt. Dabei wird das 
Senden der Nachricht SIP:PRACK vom Server S so lange verzo- 
gert, bis die Nachricht 200 OK vom Teilnehmer A empfangen 
wurde. 

25 Als Variante konnen die Daten SDP [A] unabhangig von der 

Obermittlung mit einer gesonderten Nachricht SIP:xxx in jedem 
Fall mit der Nachricht SIP:ACK (SDP [A]) iibermittelt werden. 
Somit werden von dem Server S auch Media Gateways MG unter- 
stutzt,, deren zugeh6riges IP-PSTN Gateway MGC den Empfang 

30 einer gesonderten Nachricht SIP:xxx nicht untersttitzt . 

Fur den Fall, dass der Teilnehmer B abhebt, bevor der Teil- 
nehmer A den an ihn ergangenen Ruf annimmt, kann bspw. uber 
ein Bearer Redirection Verfahren eine Ansage fur den Teilneh- 
35 mer B angelegt werden, dass es sich urn einen VoIP Call han- 
delt und der Teilnehmer B einen Augenblick bis zum Zustande 
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kommen der Verbindung warten mdge. 

Sobald der Web/Application Server S beide Nachrichten 200 OK 
auf die ausgesendeten Nachrichten SIP: INVITE empfangen hat, 
5 beginnt er mit der Vergebiihrung des Gesprachs CALL. Die Ver- 
gebiihrung endet, sobald der Web/ Application Server eine Nach- 
richt SIP: BYE von einem der beteiligten Endpunkte empfangt. 
Dabei wird z.B. ein abschliefiender Datensatz fur die Verge- 
biihrung geschrieben. 

10 

Gemafi einer weiteren Ausfiihrung der Erfindung wird in zykli- 
schen Abstanden das Bestehen des Bearers RTP uberpruft. Vor- 
teilhaf t kann so bei einem Absturz der Client Software C die 
Vergebiihrung beendet werden. Das Protokoll SIP enthalt zu 
15 diesem Zweck einen Session Timer Mechanismus, welcher hier 
beispielsweise zur Anwendung kommen konnte. 

Abschliefcend sei betont, dass die Beschreibung der fur die 
Erfindung relevanten Komponenten des Kommunikationsnetzes 

20 grundsatzlich nicht einschrankend zu verstehen ist. Fur einen 
einschlagigen Fachmann ist insbesondere of f ensichtlich, dass 
Begriffe wie Applikation, Client, Server, Gateway, Control- 
ler, etc... funktional und nicht physikalisch zu verstehen 
sind. Somit konnen beispielsweise die Endpunkte A, B auch 

25 teilweise oder vollstandig in Software und/oder iiber mehrere 
physikalische Einrichtungen verteilt realisiert werden. 
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Pat en tan spriiche 



1. Verfahren zur Verbindung von Teilnehmern mit zumindest 
5 eihem Kommunikationsnetz, umfassend folgende Schritte: 

. - Erfassung von einen ersten Teilnehmer (A) und einen zwei- 
ten Teilnehmer (B) kennzeichnenden Daten durch einen Ser- 
ver (S) , 

, - Aufbau einer ersten Signalisierungsverbindung (SIP [A]) 
10 zwischen dem Server und dem ersten Teilnehmer und einer 

zweiten Signalisierungsverbindung (SIP [B] , SS7 , DSS1) 
zwischen dem Server und dem zweiten Teilnehmer unter Be- 
rucksichtigung der Daten, 

Zusammenfuhren der beiden Signalisierungsverbindungen zu 
15 einer durchgangigen Signalisierungsverbindung (SIP, SS7, 

DSS1) zwischen den beiden Teilnehmern. 

2. Verfahren nach Anspruch 1, 

bei dem der Server als WEB Applikation (APL) ausgebildet 
20 ist, auf die insbesondere uber ein Internet (IN) und/oder ein 
IP basiertes Protokoll (HTTP) zugegriffen wird. 

3. Verfahren nach dem vorstehenden Anspruch, 

bei dem als kennzeichnendes Datum die IP Adresse erfasst 
25 wird, mit der auf die WEB Applikation zugegriffen wird. 

4. Verfahren nach dem vorstehenden Anspruch, 

bei dem im Fall eines Zugriffs mit Hilfe einer mit der IP 
Adresse - insbesondere mit Port 5060 - adressierten Anfrage 
30 festgestellt wird, mit welcher Software der auf den Server 
zugreifende Teilnehmer Inf ormationen in das Kommunikations- 
netz ubermittelt . 
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5. Verfahren nach einem der vorstehenden Ansprtiche, 

bei dem die Identitat von auf den Server zugreifenden Teil- 
nehmern unter Beriicksichtigung der erfassten Daten bestimmt 
wird. 

5 

6, Verfahren nach dem vorstehenden Anspruch, 

bei dem zur Bestimmung der Identitat des Teilnehmers eine 
erstmalige Registrierung vorgenommen wird, bei der die Iden- 
titat eindeutig kennzeichnende Daten erfasst werden. 

10 

7- Verfahren nach einem der vorstehenden Anspriiche, 
bei dem von dem Server der Austausch von Inf ormationen unter- 
stiitzt wird, die fur die Einrichtung eines Bearers (RTP, TDM) 
zwischen den Teilnehmern erforderlich sind. 

15 

8. Verfahren nach dem vorstehenden Anspruch, 

bei dem das Bestehen des Bearers von dem Server - vorzugswei- 
se durch Einsatz eines Timer Mechanismus - uberpriift wird. 

20 9. Verfahren nach einem der beiden vorstehenden Ansprtiche, 
bei dem von dem Server zumindest ein Vergebtihrungsdatensatz 
protokolliert wird, aus dem zumindest die Zeitdauer des Be- 
stehens des Bearers abgeleitet werden kann. 

25 10. Verfahren nach einem der vorstehenden Anspriiche, 

bei dem der Server einem PSTN Betreiber zugeordnet ist. 

IX. Verfahren nach den beiden vorstehenden Anspriichen, 
bei dem die Vergebuhrung fur diejenigen Teilnehmer, die dem 
30 PSTN des Betreibers zugeordnet sind, iiber die Fernmelderech- 
nung des PSTN Betreibers erfolgt. 
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12. Computerprogrammprodukt <P) - insbesondere VoIP Client 
Oder WEB Application (APL) - umfassend Sof twarecodeabschnit- 
te, mit denen ein Verfahren nach einem der vorstehenden Ver- 
fahrensansprtiche durch zumindest einen Prozessor ausgefiihrt 

5 wird. 

13. Vorrichtung - insbesondere WEB Oder Applikation Server 
(S) - umfassend Mittel zur Durchfiihrung eines Verfahrens nach 
einem der vorstehenden Verf ahrensanspruche . 

10 

14. Anordnung - insbesondere hybrides Kommunikationsnetz (IN, 
PSTN, MG, MGC) - umfassend die zur Durchfiihrung eines Verfah- 
rens nach einem der vorstehenden Verf ahrensanspriiche erfor- 
derlichen Compute rprogrammprodukte und/oder Vorrichtungen . 
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